In graphical modeling environments, such as a model-based design tool, block diagram models can be created to represent a design, or algorithm, of an implementation for a computational hardware. One or more block diagram models may represent a design for a target hardware platform. A target hardware platform used in this application may include a single computational hardware component or multiple computational hardware components. A target hardware platform may also have other elements such as memory, interfaces, or other integrated circuits (ICs). A computational hardware component is used to mean any hardware component with computational capability, such as a digital signal processor (DSP), general-purpose processor (GPP), microcontroller, application specific integrated circuit, field-programmable gate arrays (FPGA) or the like.
An automatic code generation application can automatically generate code and build programs from the block diagram model for implementation on the computational platform based on the design. In this manner, the design of a block diagram model behaves as an implementation specification for automatic code generation. A graphical block diagram modeling environment can be used to produce designs and algorithms that can be implemented on computational hardware components such as DSPs, GPPs, microcontrollers, ASICs, or FPGAs.
For a model-based design that represents a computational algorithm intended for implementation on a single computational component, such as one processor, the automatically generated code implementation of the design can be relatively straightforward. However, a block diagram model may represent a design for implementation on a hardware platform that may include multiple computational hardware components, for example, an embedded control system with multiple different processors and FPGAs. In another example, a block diagram model design which may be implemented in code to run on a single processor instead may be retargeted to run on multiple processors for a variety of design reasons, such as quality, cost, speed, etc. In these examples of multiple computational hardware components, it is much more challenging and difficult to generate an implementation by automatic code generation, from a model-based design since the implementation is dependent on the topology of the hardware. An arbitrary partitioning of a block diagram model across the multiple computational hardware components or a partitioning scheme that does not consider attributes of one or more computational hardware components may not yield intended results and fail to meet certain design requirements.
The process of partitioning a block diagram model is not a trivial task because there are many degrees of freedom one can consider to partition a block diagram model. Requirements of a block diagram model, such as input and output signal rates, timing constraints, computational load, maximum system latency, and attributes of a target hardware platform, such as computational processing capacity of each computational component, the speed of different interfaces, the type and size of memory, are variables one may consider while determining a partitioning scheme of a block diagram model. Moreover, with the wide range of possible combinations of processor and integrated circuit (IC) components that can reside on a target hardware platform, the partitioning of a model-based design is further complicated as these components can be interfaced together by a wide range of different types of physical, communication and control interfaces.
Furthermore, computational hardware components, such as GPPs, microcontrollers, and DSPs, often include one or more types of memory with varying memory access rates. For example, an embedded system may have DSPs, where each processor may contain on-chip random access memory (RAM) and/or read-only memory (ROM). Furthermore, each DSP may also access external RAM memory and the multiple DSPs may share the same external memory. On-chip internal memory is typically faster but smaller in size than the external memory. How code and data are placed in memory affects the performance of a model-based design implementation and the burden on the partitioning, in terms of memory mappiong, of the model further increases.
It is often burdensome to translate a model created in the graphical modeling application to a format suitable for execution on a target hardware platform. This burden becomes greater when the code representative of the model is partitioned across multiple computational components. This process of partitioning is often performed in manual trial-and-error fashion with little or no assurance of convergence to an optimal solution or a suitable solution. Given a specific model design, it is often hard to discern whether a particular target hardware platform is suited for the implementation of a specific design without actually testing the implementation on the target hardware platform. It is often impractical, costly and time consuming to acquire multiple hardware platforms variants to perform actual trial implementations. Additionally, the hardware platform may not be available. On the other hand, given a particular target hardware platform, it is hard to determine whether a design will execute as intended on the particular target hardware platform without actually generating code from the model design and executing the code on the target hardware platform. Therefore, there is a need for a tool that provides a quantitative assessment of any candidate partitioning scheme on the target hardware platform prior to code generation and actual execution.